The present invention is to be applied in a moving network, wherein multiple mobile routers (MR) share the same network prefix and preferably also have a mutual home agent (HA).
The following section illustrates a moving network involving multiple mobile routers. A scenario with Vehicle Area Network (VAN) with Multiple MRs is illustrated in FIG. 1 and comprises a network within a public transportation vehicle (e.g. bus, train, airplane). The internal network within the vehicle is some sort of switched Ethernet which may have both Ethernet ports and WLAN access points (APs) deployed. The internal network also has multiple MRs, as illustrated in FIG. 1, which act as gateways for external communication for all nodes inside the vehicle. The MRs are also responsible for mobility management for the entire network, i.e. mobility management is totally transparent to the nodes entering the vehicle. This means that no new requirements are put on the client nodes also known as the Mobile Network Nodes (MNNs)). The MRs share the same HA and the same network prefix from the address range of the home network. This facilitates their shared responsibility for the mobility management of the moving network. For instance, using one and the same HA simplifies administration and sharing the same network prefix avoids the problem of synchronizing source address selection and router selection.
A reason for having multiple MRs may be to provide several external accesses to the VAN, possibly using several different access technologies. In this scenario example there are two MRs in the VAN, providing external access via the three different access technologies GPRS, WCDMA, and satellite. Several of these accesses can be available at the same time depending on for instance coverage and operator policies. There are several reasons motivating why support for simultaneous usage of several accesses is beneficial in this scenario, including e.g. robustness, increased aggregated bandwidth and different application/user requirements/preferences.
FIG. 1 also shows the home network and the home agent (HA) that the MRs are communicating with. The MRs will need to establish one tunnel to the home agent for each available external access. The example in FIG. 1 shows three tunnels from the MRs (two from the MR1, one from MR2) to the home agent.
The present invention builds on the NEMO Basic Support protocol described in Vijay Devarapalli et al., “Network Mobility (NEMO) Basic Support Protocol”, RFC 3963, January 2005.
Further, the present invention assumes extensions to the NEMO Basic Support protocol with functions needed to enable multiple mobile routers to share the same network prefix.
The NEMO Basic Support protocol is defined for IPv6 only. It allows a mobile router (MR) to maintain a stable network prefix (denoted Mobile Network Prefix, MNP) for a moving network, even as the MR changes its, and thus the moving network's, point of attachment to a fixed network infrastructure.
The prefix stability is achieved through a Mobile IPv6-like solution by making a home agent (HA) a fixed point of presence for the MR and maintaining connectivity between the HA and the MR through a bi-directional tunnel. The prefix is allocated from the address range of the home network, i.e. the subnet to which the HA is attached, and can thus remain the same even as the MR and its network moves. When the MR attaches to a network in a new location, it acquires a new care-of address, but its home address and prefix are unchanged. However, just like in Mobile IPv6 (MIPv6) [described in D. Johnson et al., “Mobility Support in IPv6”, RFC 3775, June 2004) the MR has to register its new care-of address in the HA in order to maintain the MR-HA tunnel.
The nodes belonging to the network cluster that moves along with the mobile router are called Mobile Network Nodes (MNNs). In NEMO Basic Support they will not change their configuration as the MR changes its point of attachment. In other words, the mobility is transparent to them.
Presently the NEMO Basic Support protocol allows only a single care-of address to be registered in the HA for a certain MR at any one time. Multiple simultaneous care-of addresses are not allowed and thus multiple simultaneous accesses and MR-HA tunnels are not possible for a MR.
Furthermore, the NEMO Basic Support protocol assumes that the MR is preconfigured with the network prefix that is allocated to the MR out of the address range of the home network (or other prefix range supported by the HA).
As an option in the NEMO Basic Support protocol, the MR and the HA uses a regular routing protocol between each other on their mutual “link”, i.e. through the MR-HA tunnel. With this option the HA does not have to have any special intelligence to handle announcement of prefixes that are being used by “active” MRs (i.e. MRs that have valid bindings in the HA). This is instead handled automatically by the routing protocol in the regular manner.
A dynamic moving network scenario with a Personal Area Network (PAN) with Multiple MRs that provide the external access to the PAN is illustrated in FIG. 2.
The PAN can for instance be the gadgets/devices that the user is carrying with him/her or the network within the user's personal car. The PAN consists of a switched Ethernet network based on for instance Bluetooth running the PAN profile. The MRs act as routers within the PAN as well as for external network access. The MRs are also responsible for mobility management of the moving network, i.e. the PAN. As in the VAN with multiple MRs scenario, the MRs in the PAN share the same HA and the same prefix from the address range of their home network.
The external accesses provided by the MRs can for instance, as in this scenario example, consist of a cellular phone providing WCDMA access and a PDA providing WLAN access. These accesses may be available at the same time. The benefits of having multiple MRs and multiple external accesses are more or less the same as in the VAN with multiple MRs.
The MRs are communicating with the home agent (HA) deployed in the home network. The MRs need to establish a tunnel to the home agent for each available external access. The example in FIG. 2 shows two tunnels from the (single/merged) PAN to the home agent.
The PAN is an example of a potential dynamic moving network scenario whereby the owner's different devices can together form a single PAN or several “sub-PANs” (with one or more MRs in each “sub-PAN”) and changes between these two states may occur dynamically. Even though the user more or less brings a number of devices along in his/her daily life, the devices may not be close enough to each other to communicate at all times. A couple of devices may for instance be left at the user's office desk, while others are brought to a meeting. In another example some of the devices in the user's PAN more or less never leave the home. They are part of the merged PAN together with the user's mobile devices when the user is at home, but when the user is away from home his/her home devices form one sub-PAN and his/her mobile devices form another sub-PAN. Still, the home devices may stay connected to a network infrastructure to allow communication in general and specifically to allow the user to communicate with the home devices, e.g. for retrieving information (e.g. from a surveillance camera) or for remote control (e.g. house heating or the kitchen oven). FIG. 2 illustrates this potential dynamics.
Another dynamic scenario with a train is illustrated in FIG. 3 and involves a train with multiple cars. The cars may be connected and disconnected in various combinations. In order for each car to be able to function independently, each car has one or more (typically one) MR(s) with external access(es) and one or more access point(s) (AP(s)) for the MNNs constituting an independent moving network. When two cars are connected, their respective moving networks are merged (through a simple connector or a layer 2 bridge device). Thus, the network devices in all the cars of a train typically constitute a single moving network with multiple MRs.
When a car is disconnected from a train, the moving network is divided into two moving networks, one in the disconnected car and the other one in the remaining car(s).
The MRs of the moving network becomes resources that are shared by the MNNs, i.e. the MRs together serve the moving network, providing the MNNs with external network access (e.g. through WCDMA, GPRS and/or a satellite link, as depicted in FIG. 3).
An MR may be a separate node or merged with an AP. In addition, the MRs (and the moving networks of the respective cars) may be merged/connected via wireless links instead of wires. In such a scenario all MNNs and MRs will not necessarily be able to hear (i.e. be within radio communication range) of all other MNNs and MRs.
Naturally, it is also possible to have a single MR in the entire train, e.g. in the train's engine, which single-handedly serves the moving network of the entire train, but this option suffers from a number of disadvantages:
The external connectivity from a car is dependent on its connection with an engine with a MR. If a car, or a set of cars, is disconnected from the engine, e.g. during reshuffling of cars among different trains, the external connectivity is broken.
Unless all engines are equipped with MRs, an upgraded car (i.e. a car with connectivity) will sometimes not be able to serve its users with external connectivity, because it happens to be connected to a “legacy” engine without a MR. The same problem occurs if there is a “legacy” car without connectivity in the train (unless this car is located at the end of the train). Therefore, due to the bad migration properties, all cars behind the “legacy” car will be disconnected from the engine MR and will thus have no external connectivity.
In order for the engine MR to provide external connectivity to a car, all the cars between the engine and the concerned car have to support connectivity. A train company might not want to equip e.g. cooling cars or cargo cars with connectivity means and it may not want to be limited to placing such cars at the end of the train either. That implies that the flexibility is bad.
The MR deployed in an engine has to be dimensioned for the worst case, i.e. largest conceivable train. If, in contrast, MRs are placed in each car, the MR capacity of the moving network in the train inherently handles scaling to different sizes. Each car that is added to the train would then also add the MR capacity that it needs to the moving network. The rigid dimensioning wastes performance, due to poor or no dynamic scalability.
A single MR in a train is a weakness in a wireless environment, because it represents a single point of failure in terms of radio contact. The MR may have several redundant interfaces using different wireless technologies, but nevertheless it is a disadvantage when the access links with the highest capacity, e.g. WLAN, are unavailable. In addition, in certain situations all the MR's access links may be simultaneously unavailable, e.g. when the train passes through a tunnel that has no specific support for wireless communication installed. If instead a MR is placed in each car, wireless transceivers and antennas are distributed throughout the train. This increases the chance that at any given moment at least one or a few MRs have access to the highest capacity access. It also greatly reduces the risk that the train looses all its external access links simultaneously.
A single MR in a train is itself a single point of failure. When the MR is out of service due to restarts, software or hardware errors, the entire train looses its external communication possibilities. The countermeasures, duplicate MRs in the engine, or a single MR with advanced internal redundancy and error correction properties are expensive and a waste of resources (since abundant resources that seldom are used are deployed). With a MR in each car robustness is inherently achieved through the redundancy that the multiple MRs provide for each other.
Further, a single MR serving an entire train has to bear all the load of the external traffic itself. It is therefore desired to have multiple MRs, since a distributed MR principle with multiple MRs provides inherent possibilities for load sharing. It would be more efficient to provide high external access link capacity by aggregating the access link capacity of distributed multiple MRs than to equip a single engine MR with an excess of external access interfaces in order to be able to handle the most capacity-demanding cases.
Although the NEMO Basic Support protocol is limited to a single MR and a single MR-HA tunnel, the present invention assumes extensions to the scope and mechanisms of the NEMO Basic Support protocol to encompass and support multiple MRs as well as dynamic prefix assignment, i.e. a mechanism allowing a HA to dynamically assign a prefix to a MR.
The MRs of a moving network are assumed to share the same HA, in order to simplify administration, and the same network prefix, in order to avoid the problem of synchronizing source address selection and router selection.
Although the NEMO Basic Support protocol does not prevent two MRs from having the same network prefix, there is no explicit support for this either. Therefore, in view of the problems associated with such scenarios, using the NEMO Basic Support protocol for MRs sharing the same prefix may result in serious malfunctioning.
When multiple MRs share the same network prefix, it must be ensured that the MRs are actually attached to the same link, e.g. by using a local connectivity test. Otherwise inconsistent routing tables and malfunctioning routing in the HA will occur. As a concrete example, a packet destined for MNN X, connected to link α via MR A may instead be routed to link β via MR B, because MR A and MR B share the same network prefix on which the routing is based.
Thus, one side of what could be labeled “prefix consistency” is that MRs sharing the same prefix must be connected to the same moving network in order to ensure properly functioning communication and avoid routing problems. The other side of prefix consistency is that all MRs connected to the same moving network should use the same prefix. Otherwise other routing and communication problems arise. The reason is that a MNN will build an IP address from all prefixes that are advertised in the moving network, but it is not required to associate a prefix (or its resulting IP address) with the MR that advertised it. Hence, a MNN can choose any of its addresses as the source address of a packet and choose to send the packet to any of the available MRs, and these two choices (source address selection and MR selection) are independent of each other. If a MNN e.g. chooses to use an address with prefix A as the source address and sends the packet to a MR that uses prefix B instead of A, then the packet will most likely be dropped by ingress filtering. Ingress filtering can occur in the MR, but it may also occur in nodes beyond the MR, e.g. in the HA.
The management of the prefix such that prefix consistency is achieved is particularly a challenge when the mobile network is involved in a split or a merger.
The Internet-Draft “Token based Duplicate Network Detection for split mobile network (M. Kumazawa et al., “Token based Duplicate Network Detection for split mobile network (Token based DND)”, Internet-Draft: draft-kumazawa-nemo-tbdnd-2, July 2005) describes a solution that has as one of its purposes to enable detection of a moving network split.
The solution is based on a token that is associated with a prefix. The MR that “owns” the prefix generates the token and sends it to the HA in the Binding Update (BU) and then includes it in its Router Advertisements. If another MR subsequently sends a BU with the same prefix in the Mobile Network Prefix option it has to include the token associated with the prefix (assumedly received in a Router Advertisement from the “owner” of the prefix). The HA compares the prefix and token with the ones it has previously stored and if they match, the MR is accepted as a “borrower” of the prefix. If the MR fails to supply this token or supplies another token, the HA will not accept the MR as a “borrower” of the prefix.
A “borrower” of a prefix supports the “borrowed” prefix for routing purposes, but does not advertise its associated token in its Router Advertisements. The “owner” of a prefix repeatedly updates the associated token during Binding Update procedures.
If a moving network is split such that the “owner” and the “borrower” of a prefix ends up in separate moving networks, the HA will eventually discover this. The “borrower” of the prefix will not be able to refresh its right to use the prefix (during a Binding Update procedure), when the “owner” of the prefix (the “borrower” unknowingly) has updated the associated token.
The token based solution has several disadvantages. A major drawback is its poor temporal properties. The age of a verified local connectivity depends on the token update period, which is no better than the Binding Update period. This directly translates into the time required to detect a moving network split and the regular Binding Update period is far too long.
A security related problem is that the solution has no protection against a malicious MNN or MR that hi-jacks the token and pretends to be the owner of the prefix. Thus, a malicious node may trigger a false split detection (by falsely updating the token) or, at least temporarily, hide a true moving network split (by advertising the token).